I know much to nothing about our database connections, maybe @ehuss or @Kobzol knows about it, and if this conceptually a good idea.

Just quickly looking at this, it seems like it might have a few issues.

• It doesn't look like it manages the permit. That means the permit count and the pool count could get out of sync, allowing more connections than the semaphore is intended to allow.
• This doesn't directly address Scheduled jobs often fail due to db timeout #1887, which is more of a theory about idle connections being terminated, and not knowing that until it has been popped off the queue.
• If the connection is broken, checking it in get() isn't going to help, since the call to validate_connection could hang, which would be no different from just running a normal query.

When I have more time, I can maybe look at some suggestions. Or maybe @Kobzol has more time right now.

Tbh I don't think that this is the right approach, as we aren't even sure what was the cause of the original issue. These timeouts also happen in rustc-perf, and it's IMO caused simply by the DB not responding due to being overloaded or a perhaps a network issue. The DB server has been beefied up recently, so maybe these issues aren't even happening anymore? It seems like they stopped happening on rustc-perf once the server was upgraded. So I would keep the connection pooling like it is for now.

Ok, because I have encountered similar problems before, but there may be various reasons for the original issue. Thank you three for review! I'll close it.